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WIRELESS WAGERING SYSTEM 



CROSS REFERENCE TO RELATED APPLICATIONS 

[0001] This application is a divisional of U.S. Application No. 10/01 1,648 filed on 
5 December 4, 2001. 

BACKGROUND OF THE INVENTION 

[0002] The present invention relates to gaming devices in general and, more 
specifically, to portable gaming devices suitable for use in gaming establishments such 
10 as casinos and bingo halls. 

[0003] In recent years, radio-controlled hand-held or portable electronic bingo 
devices, such as disclosed in U.S. Patent Nos. 4,455,025 and 4,624,462 both to Itkis 
and in bingo industry publications, including an article "Bingo Playing Enhanced With 
New Innovations", Bingo Manager, July, 2001 , gained substantial popularity in casinos. 
15 However, mobile electronic bingo devices have limited applications in a casino 
environment and are labor-intensive because of the need to download bingo cards at 
a point-of-sale terminal operated by a cashier. 

[0004] Recently, portable remote gaming devices were proposed for playing 
"classic" casino games such as poker, slots and keno. In particular, U.S. Patent Nos. 

20 6,01 2,983 and 6,001 ,016 both to Walker, et al., propose to utilize pager-like devices for 
remote monitoring of the progress of a slot game executed automatically on a player's 
behalf on an actual slot machine available at a "casino warehouse." However, Walker 
limits play to a rather passive observation of the game and, therefore, diminishes a 
player's interest in the game. Besides, Walker's approach requires a costly investment 

25 in real slot machines located remotely at a "casino warehouse." In addition, Walker 
does not provide any mechanism for facilitating the labor-intensive process of 
distributing gaming devices to players and does not assure security of the gaming 
devices. A commercial implementation of remote playing on a "warehoused" slot 
machine by GameCast Live as disclosed in "Expanding Casino Borders", International 

30 Gaming and Wagering Business, September 2001 , suffers from the same deficiencies 
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as Walker's disclosures. Moreover, although GameCast Live offers players convincing 
video and audio data streams originating at video cameras aimed at actual slot 
machines, such implementation is labor intensive and requires costly hardware. In 
addition, such an approach cannot provide a casino with an adequate number (e.g., 
5 several hundred) of remote wagering devices since the overall radio frequency (RF) 
bandwidth available for a casino is severely limited. 

[0005] On the other hand, a cellular telephone-based approach to remote gaming 
being promoted by companies, such as Motorola, Inc., TRIMON Systems, Inc. and 
NuvoStudios, Inc., as disclosed, for example, in "NuvoStudios, Inc., Corporate Profile", 

1 0 NuvoStudios, Inc., October 2001 and "Mobile Casino Solution", TRIMON Systems, Inc., 
October 2001, does alleviate the issue of available radio frequency bandwidth. Yet, 
remote gaming on cellular telephones is functionally indistinguishable from gaming on 
the Internet. Although casinos are tempted by the lucrative prospects of Internet 
gaming, such as described in U.S. Patent Nos. 5,800,268 to Molnick, 5,999,808 to La 

1 5 Due and 5,779,545 to Berg et al., the disclosed Internet wagering techniques cannot 
be directly transplanted into casino environment because of the vast differences 
between the security and integrity requirements of "brick-and-mortar" casinos and 
"click-and-mortar" casinos. While there is no conceivable motivation for an Internet 
player to sabotage his or her own personal computer (PC), telephone or mobile 

20 Personal Digital Assistant (PDA), an unscrupulous player will not hesitate to subvert a 
casino slot machine. In addition, a potentially unscrupulous player is thwarted from 
cheating on the Internet by the fear of violating a vast plethora of laws and regulations 
aimed to prevent wire fraud and credit card fraud. In comparison, the intra-casino 
operation of slot machines is typically outside of purview of such anti-fraud laws. Being 

25 functionally equivalent to gaming on stationary Internet terminals, wireless gaming on 
Internet-enabled phones and PDAs suffers from the same serious security and integrity 
deficiencies that are inherent in stationary Internet terminals. 

30 
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SUMMARY OF THE INVENTION 

[0006] It is the primary objective of the present invention to provide a casino player 
with an opportunity to securely play casino games, such as poker, slots, keno and 
bingo "on the go" without the need for a stationary video and/or reel slot machine. 
5 [0007] It is a further objective of the present invention to provide a casino player 
with a secure method of playing a mobile casino game on a small device convenient 
for carrying on the person. 

[0008] It is a further objective of the present invention to automate the process of 
renting such mobile wagering devices to players. 
10 [0009] Yet another objective of the present invention is to automatically track 
mobile player devices rented to players to encourage the return of the devices to the 
casino. 

[0010] These and further objectives will become apparent from the attached 
drawings and the following description of the preferred embodiment. 

15 [0011] The above objectives are achieved through the present invention by 
providing a casino player with a wireless wagering device akin to a wireless PDA or an 
Internet-enabled cellular telephone. The preferred embodiment of a mobile wagering 
device, programmed to play typical casino games, including poker, slots, keno and 
bingo, incorporates a radio frequency transceiver, an infrared downloading port and a 

20 rechargeable battery. A player rents such a mobile player unit from the casino at a self- 
service dispensing kiosk. In order to rent a mobile player unit, a player inserts a player 
club card into the kiosk's magnetic card reader and deposit money into the kiosk's bill 
validator The kiosk houses a number of mobile player units in its storage and 
recharging cells. Each of the cells are networked over a local area network with a 

25 central PC-compatible computer controlling the kiosk. 

[0012] When a player buys a pack of electronic bingo cards at a kiosk, the kiosk's 
central computer downloads the purchased bingo cards into an available player unit 
plugged into the internal local area network of the kiosk while the unit is housed in the 
kiosk. A player can then take the downloaded unit out of the kiosk to any location of 

30 the casino floor. Over a radio channel, the unit receives bingo data, such as bingo 

-3- 



5896.00025 

patterns and pseudo-random bingo numbers from the kiosk's central computer, and 
plays downloaded bingo cards automatically. The central computer automatically 
verifies all bingo cards downloaded into all rented mobile player units, detects winning 
bingo cards, computes the prizes due to the winning players and stores the outcomes 
5 of the games in an internal database. When a player re-inserts the player unit into the 
kiosk, the kiosk automatically dispenses any winnings due the player through a bill 
dispenser and/or coin hopper. 

[001 3] The central computer also maintains a database of the rented units and may 
award bonus points to players returning the rented units to the kiosk. A complete self- 
10 service rent-and-return cycle yields substantial labor costs savings for casinos. The 
kiosk is also equipped with electronic latches controlled by the central computer. The 
latches lock the unit inside the kiosk and prevent a player from taking the unit out of the 
kiosk without first paying for the unit. 

[0014] A player having a sufficient account balance can also purchase, by means 
1 5 of radio communications, bingo cards with the help of the mobile player unit located on 
the casino floor. In order to prevent fraud and make radio communication with the unit 
secure, the central computer downloads an encryption key to each unit being rented. 
The encryption key is downloaded over the kiosk's internal local area network while the 
unit remains locked inside of the kiosk. Even though a radio communication can be 
20 easily intercepted, such an internal downloading of the encryption key assures security 
of the subsequent communications between the central computer and the rented unit 
over the public radio channel. As a result, a player can confidently place an order for 
purchasing bingo cards right from the casino floor in real time. 
[0015] Moreover, secure gaming over a public radio channel authenticated by an 
25 encryption key downloaded at a dispensing kiosk opens an opportunity for playing 

* 

"classic" casino games, such as poker and slots, on the very same mobile player unit. 
In this case, the player unit transmits authenticated encoded game requests, such as 
"deal a poker hand", "spin reels" and "draw keno balls", to the central computer. In 
response, the central computer broadcasts authenticated outcomes of the games 
30 determined by a software random number generator running on the central computer. 
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The response received by the player unit determines the outcome of the game 
including winnings, if any, and a new credit balance. Each such request and response 
thereto are authenticated by digital signatures based upon a secure authentication key 
downloaded into the player unit from the central computer while the player unit remains 
inside the dispensing kiosk. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0016] The invention is illustrated by the following drawings: 

[0017] Fig. 1 illustrates a block diagram of the preferred embodiment of the present 
invention; 

[0018] Fig. 2 illustrates a local area network of the present invention; 

[0019] Fig. 3 illustrates a block diagram of a player unit of the present invention; 

[0020] Fig. 4 illustrates a locking mechanism of the present invention; 

[0021] Fig. 5 illustrates a status table of the present invention ; 

[0022] Fig. 6 illustrates a player-tracking card of the present invention; 

[0023] Fig. 7 illustrates a rental receipt of the present invention; 

[0024] Fig. 8 illustrates a flowchart of a "dispense unit" task of the present 
invention; 

[0025] Fig. 9 illustrates a flowchart of a "verify" task of the present invention; 

[0026] Fig. 10 illustrates a return receipt of the present invention; 

[0027] Fig. 1 1 illustrates a "buy pack" window of the present invention; 

[0028] Fig. 12 (a) illustrates a "bingo request" data block of the present invention; 

[0029] Fig. 12 (b) illustrates a "spin request" data block of the present invention; 

[0030] Fig. 12 (c) illustrates a "deal request" data block of the present invention; 

[0031] Fig. 12 (d) illustrates a "draw request" data block of the present invention; 

[0032] Fig. 1 3 (a) illustrates a "service request" data block of the present invention; 

[0033] Fig. 13 (b) illustrates a "service response" data block of the present 
invention; 

[0034] Fig. 14 illustrates a "initiate spin" task of the present invention; 



[0035] Fig. 1 5 illustrates a "determine outcome" task of the present invention; 
[0036] Fig. 16 illustrates a "display outcome" task of the present invention; 
[0037] Fig. 17 (a) illustrates a "deal" data block of the present invention; 
[0038] Fig. 1 7 (b) illustrates a "draw" data block of the present invention; 
[0039] Fig. 1 8 (a) illustrates a lateral communication between two player units via 
an infrared port of the present invention; and 

[0040] Fig. 1 8 (b) illustrates an infrared communication via a local area network of 
the present invention. 

t 

PREFERRED EMBODIMENT 

■ 

- * ■ 

[0041] As illustrated in Fig. 1, a preferred embodiment of the present invention 
includes two main elements, namely, a mobile player unit (MPU) 1 and a unit dispenser 
kiosk (UDK) 2. Specifically, Fig. 1 shows three mobile player units 1 located outside 
dispenser kiosk 2 and fifteen mobile player units 1 located inside kiosk 2. It is 
presumed that mobile player units 1 located outside of kiosk 2 are rented to players and 
that the units 1 located inside kiosk 2 are generally available for rent. The rented units 
1 are shown with their touchscreen liquid crystal displays (LCD) 3 facing the reader and 
with their radio-frequency (RF) antennae 4 extended, whereas mobile player units 1 
inside kiosk 2 are shown positioned on their sides 5 with antennae 4 retracted into 
respective units 1. Fig. 1 also illustrates that MPU 1 is equipped with control 
pushbuttons 6, a charger and communications connector 7 and a "UNIT READY" light 
emitting diode (LED) 8. LCD 3 of a first rented unit 1 displays an image of a bingo card, 
while LCD 3 of a second rented unit 1 displays an image of slot reels, and LCD 3 of a 
third rented MPU 1 displays an image of poker cards. Although only a few mobile 
player units 1 are shown in Fig. 1, a typical casino is expected to have hundreds of 
rental MPU 1 available for its patrons and is expected to be equipped with several 
UDKs 2 networked together. 

[0042] Being a combination kiosk-type dispenser of MPUs 1 with a central game 
controller, UDK 2 includes an assortment of conventional point-of-sale and automatic- 
teller-machine components, including a touchscreen video monitor 9, a receipt printer 
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(PRT) 10, a magnetic card reader (MCR) 1 1 , a bill validator/barcode-reader (BV) 12 a 
bill dispenser (BD) 13 and a coin dispenser CD 14. In addition, UDK 2 incorporates a 
RF antenna 1 5 being a part of an embedded RF transceiver 1 6 shown explicitly in Fig. 
2. The UDK 2 includes a plurality of storage cells 1 7. Each storage cell 1 7 is capable 
5 of housing one MPU 1 . In addition, each storage cell 1 7 is capable of recharging and 
communicating with the MPU 1 housed therein. Specifically, Fig. 1 shows thirty cells 
17 arranged in three rows often cells 17 each. Some illustrated cells 17 are occupied 
by units 1 and some cells 17 are empty as some MPUs 1 have been rented. Although 
Fig. 1 explicitly shows only thirty storage cells 17, a typical UDK 2 may incorporate 

1 0 more or less than thirty cells 1 7. 

[0043] The internal design of an MPU 1 is illustrated in Fig. 3. Being essentially a 
wireless PDA, unit 1 incorporates touchscreen LCD 3, antenna 4, LED 8, connector 7, 
control buttons 6, a programmable microprocessor 18, such as a Dragon-Ball-Z® 
microprocessor, a spread-spectrum RF transceiver 19, such as a BlueTooth® 

1 5 transceiver and a speaker 20. Also incorporated within the internal design of an MPU 
1 , but not shown explicitly in Fig. 3, are conventional dynamic and non-volatile memory 
and a rechargeable battery. 

[0044] The internal design of UDK 2 is detailed in Fig. 2. Architecturally, UDK 2 is 
a local area network (LAN) 22 governed by a conventional personal computer (PC) 21 . 
20 The internal components of UDK 2 are interfaced with each other via LAN 22. In 

■ 

particular, PC 21, BV 12, MCR 11, PRT 10, BD 13, and CD 14 are permanently 
plugged into LAN 22. An MPU 1 temporarily occupying cell 17 is interconnected with 
LAN 22 via its own connector 7 and a mating charging and communication connector 
23 on the end of cable 24 that forms a branch of LAN 22. Connector 23 is built into cell 

25 17 as shown in Fig. 4. LAN 22 also includes cables 25 through 30 forming branches 
of LAN 22 interfacing respectively with PC 21 , BV 1 2, MCR 1 1 , PRT 1 0, BD 1 3 and CD 
14. In addition, LAN 22 is wirelessly interfaced with rented MPUs 1 via a spread- 
spectrum RF channel 31, preferably, a public domain RF channel. More specifically, 
PC 21 incorporates a spread-spectrum transceiver 1 6 (shown in dashed lines) identical 

30 to the spread-spectrum transceiver 19 of MPU 1 and an antenna 15 identical to the 



-7- 



antenna 4 of MPU 1. Via transceivers 16 and 19 and antennae 4 and 15, LAN 22 is 
wirelessly interfaced with MPU 1 over a spread-spectrum RF channel 31. 
[0045] Fig. 4 illustrates three neighboring cells 1 7 of UDK 2. The leftmost cell 1 7 
and the central cell 1 7 are occupied by MPUs 1 , whereas the rightmost cell 1 7 is empty. 
As shown in Fig. 4, each storage cell 17 includes a battery charger and 
communications connector 23, for mating with connector 7 of MPU 1, and an 
electromechanical lock formed by a spring-loaded solenoid 134 (the spring is not 
explicitly shown in Fig. 4.) having a solenoid rod 32. The leftmost cell 17 shows 
solenoid 1 34 in a deactivated state with its rod 32 being forced out by the spring and, 
consequently, MPU 1 being locked inside the leftmost storage cell 17. The central 
storage cell 17 shows solenoid 134 in an active state with its rod 32 retracted and, 
consequently, MPU 1 being released. The mechanics of solenoid 134 are such that 
its rod 32 allows for easy insertion of MPU 1 into cell 1 7 but precludes removal of MPU 
1 from cell 17 without activation of solenoid 134. Although not shown explicitly, each 
storage cell 17 also includes charging circuitry for charging MPU 1 while it is inserted 
into storage cell 17. 

[0046] Via LAN 22, PC 21 periodically polls all cells 17 of UDK 2 to determine 
whether they are occupied and, if so, by which MPU 1. Note that each MPU 1 is 
characterized by its unique manufacturer's identification number 33 stored in its non- 
volatile memory and further etched on the top surface 34 of MPU 1 as shown in Fig. 1 . 
In particular, PC 21 periodically sends a test data block to each occupied cell 17 via 
respective communication connectors 23 and 7. In response to the received test block, 
MPU 1 residing in a particular cell 17 sends an acknowledgment containing its 
manufacturer's identification number 33 to PC 21 via embedded connector 7. The 
conventional details of the test and acknowledgment data blocks flowing between MPU 
1 and PC 21 are omitted herewith as they are well known to practitioners of the art. 
Once PC 21 receives a positive acknowledgment from MPU 1, it marks, in its memory, 
the respective cell 1 7 together with MPU 1 residing therein as available for dispensing 
to a player. Specifically, PC 21 maintains in its memory a status table 35 illustrated in 
Fig. 5. The status table 35 details the current status of each cell 17, each MPU 1 and 
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each casino patron renting an MPU 1 . Each row of table 35 presents status of an 
individual cell 17. Specifically, the first group 36 of thirty rows represents the current 
status of thirty individual cells 17. The individual cells 17 in table 35 are indexed by the 
cell identification number 37. The top leftmost cell 17 of Fig. 1 is identified as cell 
5 number one (1) and the bottom rightmost cell 17of Fig. 1 is identified as cell number 
thirty (30). For each storage cell 1 7, table 35 indicates the manufacturer's identification 
number 33 of mobile player unit 1 housed therein and the current status 38 of MPU 1 
located in the cell 1 7. The current status of each MPU 1 stored in a cell 1 7 is indicated 
by status flag 38 that is equal to one, if respective cell 17 houses an MPU 1 ready for 

10 dispensing, and is equal to zero otherwise. 

[0047] Players rent MPUs 1 from UDK 2 and return MPUs 1 to UDK 2 once they 
complete playing. In order to rent an MPU 1 from UDK 2, a player is preferably 
required to first insert into MCR 1 1 a player tracking card 39 as illustrated in Fig. 6, 
otherwise no MPU 1 should be dispensed by UDK 2 to the player. Along with a player's 

15 name 40, card 39 bears a player's identification number 41 . For purposes of brevity, 
a player having identification number 41 may simply be called player 41 throughout the 
remainder of the disclosure. The name 40 and identification number 41 may also be 
encoded in a magnetic form on magnetic strip 42 and may also be available in a 
barcode format 43. In order to rent a player unit, a player must, in addition to inserting 

20 player card 39 into MCR 1 1 , also deposit money into BV 1 2. 

[0048] Initially, in order to facilitate the description of the operation of the system, 
a simple case of a player renting an MPU 1 to play a prepackaged set of electronic 
bingo cards ("pack") is considered. For example, it is assumed that a casino offers 
players only one type of bingo packs and allows players to buy only one pack. A 

25 specific bingo pack sold to a player 41 is identified on a rental receipt 44 issued by PRT 
1 0 as illustrated in Fig. 7. Note that manufacturers of paper and electronic bingo packs 
design their packs in such a way that each bingo pack contains predetermined bingo 
cards and each bingo pack is identifiable by its manufacturer's pack identification 
number 100. To determine each and every bingo card to be played by player 41 in 

30 each' and every bingo game of a bingo session for which pack 43 is intended, it is 

• 

i 
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sufficient to know the pack identification number 100. The reverse is also true where 
duplicate bingo cards are not allowed in any game. 

[0049] The operations being performed by PC 21 of UDK 2 in this simplified case 
are illustrated in the flowchart of Fig. 8 illustrating a "dispense unit" task. Note that PC 
21 operates in a multitasking environment, such as Linux®, and executes multitasking 
applications software. In accordance with the instructions 120 displayed on the 
touchscreen monitor 9, a player starts by inserting a player card 39 into magnetic card 
reader 11. MCR 11 detects the inserted player card 39 and transfers a player 
identification number 33 over LAN 22 to PC 21 as illustrated by the step "READ 
PLAYER CARD" 45 of the flowchart in Fig. 8. Subsequently in the step "FETCH 
PLAYER RECORD" 46, PC 21 attempts to fetch the current player record by matching 
the read-in player identification number 33 from the status table 35. Techniques of 
searching databases are well known in the industry and, therefore, not described in 
detail herein. If as a result of the test "VALID RECORD?" 47, a matching record is not 
found in table 35, PC 21 returns to step 45 of reading player card 39. If test 47 is 
passed successfully, PC 21 begins to poll BV 12 in step "POLL VALIDATOR" 48. If a 
bill is indeed inserted, then the test "BILL IN?" 49 is deemed successful, and the 
player's balance 57 that is stored in status table 35 is incremented according to the 
denomination of the bill in step "INCREMENT PLAYER'S BALANCE" 50. Assuming the 
resulting balance 57 is sufficient to purchase a bingo pack, the test "SUFFICIENT 
BALANCE?" 51 is satisfied and PC 21 proceeds to the next step "SELECT UNIT" 52, 
otherwise PC 21 loops back to step 48. Excess deposited funds, if any, are credited 
to player's account balance 57. While performing step "SELECT UNIT" 52, PC 21 
scans table 35 and finds the next available MPU 1 ready for operation. The located 
MPU 1 is downloaded with purchased electronic bingo cards in the step "DOWNLOAD 
CARDS" 53. As techniques of downloading electronic player units with bingo cards are 
well known in the industry, they are omitted herein. Instead, it is emphasized that bingo 
cards are downloaded into MPU 1 via a secure, private communication channel formed 
by connectors 7 and 23. Note that communications via connectors 7 and 23 are not 
susceptible to interception, whereas communications via public radio channel 31 can 
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be easily intercepted. Subsequently, PC 21 updates a record of player 41 (more 
exactly, a player having identification 41) in status table 35 in the step "UPDATE 
PLAYER RECORD" 54. In particular, PC 21 updates a player's credit balance 57 to 
reflect the payment for the purchased bingo pack 43 and also links the record of player 
5 41 with the manufacturer's identification number 33 of MPU 1 downloaded with pack 
43, At this point, PC 21 causes PRT 10 to print rental receipt 44 including player 
identification number 41, identification number 33 of the rented MPU 1, identification 
number of the downloaded pack 43, receipt identification number 58 and receipt 
identification barcode 59. Barcode 59 uniquely encodes the information printed on 

10 receipt 44. PRT 10 prints receipt 44 in a format compatible with the built-in barcode 
reader of BV 12 so that the BV 12 can read barcode 59. Lastly, PC 21 activates 
solenoid 134 of the cell 17 containing the downloaded MPU 1 in the step "RELEASE 
UNIT" 56 as is illustrated by the central cell 17 in Fig. 4. Now, a player can remove 
MPU 1, carrying the downloaded information, from a respective cell 17. In order to 

1 5 assist the player in finding the MPU 1 , the MPU 1 starts blinking its LED 8 as soon as 
it detects the end of the process of downloading of, via connectors 7 and 23, pack 43 
by PC 21. 

[0050] Once player 41 removes MPU 1 from UDK 2, PC 21 transfers the 
identification number 33 of the removed MPU 1 from the first 30 rows 36 of table 35 to 

20 the group of records 70 that lists "homeless" MPUs 1 (i.e., units not housed in any 
specific cell 1 7 and, presumably, located somewhere on the casino floor). As illustrated 
in Fig. 5, each "homeless" unit listed in group 70 however is "temporarily owned" by a 
specific player 41 and visa versa each player 41 becomes linked by PC 21 with a 
specific MPU 1 having a specific identification number 33. Note that the last group of 

25 records in table 35, namely group 1 33, is essentially a player club database that stores 
a player's remaining balances 57 and bonus points 68 once the player returns a MPU 
1 to UDK 2. 

[0051] Once removed from UDK 2, a player can carry a rented MPU 1 anywhere 
through a casino and, as long as MPU 1 receives bingo data over RF channel 31 , it will 
30 play bingo automatically as illustrated in the flowchart of Fig. 9 illustrating a "verify" task. 
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Specifically in the step "RECEIVE BROADCAST" 60, MPU 1 receives bingo data, such 
as called bingo numbers and bingo patterns, broadcast by UDK 2 to all MPUs 1 via 
antenna 1 5. Note that the broadcast data does not have to be encrypted because it is 
not necessary to encode publicly known data, such as called bingo numbers and bingo 
5 patterns being played. In particular, MPU 1 checks for new called bingo numbers in the 
test step "NEW #?" 61 and for new bingo pattern in the test step "NEW PATTERN?" 
62. Should any new data be discovered, MPU 1 marks electronic bingo cards in its 
memory in accordance with the received new data in the step "MARK CARDS" 63. 
Otherwise, MPU 1 loops back to step 60. Once MPU 1 marks cards, it sorts the 

10 marked bingo cards in accordance with their closeness to winning and displays the 
best bingo cards on its screen 3 in the step "DISPLAY BEST CARDS" 65. In particular, 
if MPU 1 detects a card that achieved bingo, MPU 1 immediately displays the winning 
card 66 on touchscreen 3 and continuously blinks card 66 to attract a player's attention. 
In addition, MPU 1 may play a winning tune through speaker 20. 

1 5 [0052] The data broadcast by UDK 2 over antenna 1 5 originates at PC 21 . PC 21 
stores a schedule of bingo games or patterns to be played in its memory in a 
conventional way. PC 21 also utilizes a standard random number generation utility to 
generate randomly called bingo numbers. As an alternative, a conventional ball hopper 
or. bingo rack may be used to generate random bingo numbers. PC 21 also 

20 automatically verifies all sold bingo cards (i.e., bingo cards downloaded in each rented 

■ 

MPUs 1), with each new called bingo number in order to detect a winning card as 
taught by U.S. Patent No. 5,951 ,396 to Tawil and is further disclosed in applicants' co- 
pending U.S. Patent Application No. 60/241,982 entitled "Fully Automated Bingo 
Session." Once a winning card is detected, PC 21 algorithmically computes the 
25 identification number 1 00 of bingo pack 43 that the winning bingo card was downloaded 
to'. "Knowing the winning pack number 43, PC 21 finds the winning player 
corresponding to the manufacturer's identification number 33 by searching status table 
35. Once the winning player is found, PC 21 updates the player's balance 57 to reflect 
the winning prize. 

* 

I 
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[0053] Meanwhile, the winning MPU 1 independently detects a winner as described 
above and starts blinking the winning card 66 on display 3 and optionally plays a 
winning tune through speaker 20. At this point, a winning player may approach UDK 
2 and claim a prize by inserting the winning MPU 1 back into UDK 2. A player may 
5 insert MPU 1 into any empty cell 1 7. PC 21 detects the insertion of MPU 1 through cell 
17 polling procedure described above. Upon learning the physical identification number 
33 of the inserted MPU 1 , PC 21 searches status table 35 and fetches the identification 
number 41 of the player who rented the unit and also fetches the player's account 
balance 57 from table 35. The account balance 57 includes the player's winnings as 

10 described above. Now PC 21 causes BD 13 and CD 14 to dispense the player's 
balance due. Specifically, BD 1 3 dispenses the dollar amount of the player's balance 
57 and CD 14 dispenses the remaining amount, if any, of cents in coins. Once 
dispensing of the balance 57 is complete, PC 21 clears balance 57 in player's 41 record 
in table 35 and also clears MPU 1 manufacturer's identification field 33. The operation 

1 5 of clearing field 33 releases player 41 from any responsibility for the returned MPU 1 . 
As a courtesy to the player, PC 21 also causes PRT 10 to issue a return receipt 67 
illustrated in Fig. 10, wherein 68 is the refund value, if any, and 69 is the barcode that 
uniquely identifies and verifies return receipt 67. 

[0054] Optionally, a player may also be required to insert the barcoded receipt 44 
20 into BV 12 and/or insert the player card 39 into magnetic card reader 1 1 . If such an 
option is selected, then BV 12 reads barcoded identification 59 of receipt 44 and/or 
magnetic card reader 1 1 reads-in player identification number 41 from card 39, and PC 
21 compares read-in identifications 59 and/or 42 of receipt 44 and/or card 39 with the 
values stored in table 35. Assuming they match with the read-in identification 33 of 
25 MPU 1 stored in the player's 41 record in table 35, the validity of the winning claim is 
well-established. Some casinos may even elect to rely exclusively on the validation of 
receipt 44 and/or card 39 for purposes of paying winners without the requirement of 
returning the winning MPU 1 into UDK 2. However, the preferred requirement of 
returning the winning MPU 1 decreases the casino's labor costs since casino 
30 employees will not have to retrieve and return MPUs left all over the casino. Also, it 
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insures that MPUs 1 are readily available for new players to rent. Moreover, it prevents 
a player from taking a MPU 1 home as a "souvenir" or the like. For all such reasons, 
it makes sense for a casino to require all players to return all rented MPUs 1 to UDK 
2 once a player is finished. A casino is in a position to enforce the return of the MPUs 

5 1 because status table 35 contains detailed records of MPUs 1 rented by players. 
However, instead of enforcing the return of MPU 1, a casino may encourage a 
voluntary return by, for example, awarding a player's account bonus points 68 upon the 
return of the rented MPU 1. A player may use the bonus points 68 as discounts for 
buffets, souvenirs, etc. Also, a casino may impose a deposit fee for renting MPU 1 and 

1 0 refund the deposit to the player through dispensers 1 3 and/or 1 4, once a player returns 
the MPU 1 . 

[0055] The primary reason the above-described MPU 1 is equipped with RF- 
channel 31 is to facilitate automatic playing of bingo on the casino floor. However, 
some players and some casinos prefer manual entry of all necessary bingo data into 
1 5 the MPUs 1 as described, for example, in U.S. Patent 4,378,940 to Gluz et al., and the 

t 

article "Bingo Playing Enhanced With New Innovations", Bingo Manager, July, 2001. 
If manual entry is required, the MPU 1 does not have to be equipped with transceiver 
19 and antenna 4 resulting in a less expensive MPU 1. However, even in such a 
simplified case, the UDK 2 is still very useful since it completely automates the process 
20 of selling electronic bingo cards and yields substantial labor costs savings for casinos 

t 

and bingo halls. 

[0056] The aforementioned simple example of the system illustrated in Fig. 1 
presumes that a player purchases only one specific bingo pack 43. However, being 
equipped with touchscreen 9, UDK 2 can offer a player a choice of types and quantities 

25 of packs as illustrated in Fig. 1 1 showing a window 71 on touchscreen 9. Window 71 
displays an example of a menu of choices available to the player. Specifically, by 
touching button 72, a player can select a "REGULAR" pack costing $5.00 and by 
pressing button 73, a player can select a "SPECIAL" pack costing $9.00. Touchbuttons 
"+" 74 and "-" 75 allow a player to increase and decrease respectively the number of 

30 packs to purchase. Finally, touchbutton "BUY" 76 allows a player to actually place a 
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purchase order. PC 21 processes the player's purchase order in a conventional 
manner. 

[0057] To this point, it was assumed that bingo packs 43 are to be purchased by 
the player at the UDK 2 when the player rents MPU 1 . This is acceptable in the case 
5 of bingo games organized in sessions of one hour or more. However, in the case of so- 
called continuous bingo wherein players buy bingo cards for each game separately and 
may, for example, play some games while skipping other games, it is inconvenient for 
a player to buy bingo cards at UDK 2 separately for each game. It is therefore 
desirable to allow a player to purchase bingo packs on the casino floor, through MPU 

r 

10 1 that has an inherent capability of two-way radio communication via transceiver 19. 
For example, touchscreen 3 of MPU 1 can display the same menu 71 illustrated in 
Fig.1 1 as the touchscreen 9 of UDK 2. Once a player completes the purchase order 
by pressing "BUY" button 76, MPU 1 can send a request to purchase electronic bingo 
cards to UDK 2 via RF channel 31. In particular, MPU 1 can send a "bingo request" 

1 5 data'block 77 illustrated in Fig. 1 2(a) wherein, a data field "BINGO" 78 signifies that the 
present request is to purchase bingo packs, the next field 79 specifies the number of 
regular packs to purchase and the last field 80 specifies the number of special packs 
included in the purchase. Upon receiving a purchase request 77 from MPU 1 , PC 21 
fetches from status table 35 a record corresponding to the identification number 33 of 

20 MPU 1 and checks the current account balance 57 of the player for sufficiency of funds 
to cover the request 77. Assuming sufficient funds are available, UDK 2 transmits 
purchased electronic bingo cards to MPU 1 via RF channel 31 rather than downloading 
purchased bingo cards via connectors 7 and 23. PC 21 also decrements account 
balance 57 by the amount of the order. 

25 [0058] However, there is a serious concern with the direct two-way RF 
communication between MPU 1 and UDK 2. Specifically, such a communication over 
open RF channel 31 can be easily intercepted. The lack of security can be resolved 
by encrypting such communications with the help of a private encryption key that is 
generated by UDK 2 and downloaded into MPU 1 via a secure route formed by 

30 connectors 7 and 23. Specifically, in addition to, and/or instead of bingo cards, PC 21 
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i 

can download MPU 1 with at least one random digital security key to secure the two- 
way radio communications between MPU land UDK 2. Such a digital security key is 
typically known in the industry under a variety of names (e.g., a digital encryption key, 
DES key, an authentication key, a private key, a digital signature key, a hashing 
5 algorithm, etc.) Importantly, MPU 1 is downloaded with a new unique random 
encryption key each time MPU 1 is rented and, therefore, even if the same player 41 
accidentally rents the same MPU 1 having the same identification number 33, the 
downloaded encryption key is different every time. Optionally, the downloaded security 
key may be printed on sale receipt as is illustrated in Fig. 7 wherein the numeral 82 
10 denotes a security or encryption key. Although an explicit printing of security key 82 
may potentially result in complications in the case where a player loses receipt 44, a 
"spelled-out" key 82 facilitates auditing procedures and increases a player's trust in the 
fairness of gaming conducted by the casino. 

[0059] A random encryption key 82 is generated by PC 2 1 with the help of random 
1 5 number generation software utility in a conventional way. The details of the generation 
and utilization of key 82 are omitted herein since techniques of data encryption are well 
known in the industry and are disclosed in numerous publications including, for 
example, U.S. Patent Nos. 4,670,857 to Rackman, 5,643,086 to Alcorn et al., 
6,071 ,190 to Weiss et al., and 6,149,522 to Alcorn et al. Instead, it is re-emphasized 
20 that PC 21 downloads MPU 1 with a security key 82 over a secure communication 
channel formed by cable 24 and connectors 7 and 23 and that the security key 82 
changes with every downloading. Being downloaded with a security key 82, MPU 1 can 
send authenticated data blocks to UDK 2 over the public radio frequency channel 31. 
Specifically, each such data block is authenticated with the help of a digital signature 
25 based on the security key 82 as illustrated in Fig. 13. Similarly, each data block MPU 
1 receives from UDK 2 over the public RF channel 31 is also authenticated with the 
help of a digital signature based on the security key 82 as illustrated in Fig. 13. 

> 

[0060] Specifically, Fig.1 3 (a) shows a "service request" data block 83 originating 
at MPU 1 on the casino floor. The data block 83 starts with manufacturer's 
30 identification number 33 of MPU 1 followed by a block sequence number 84 followed 
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by a digital signature 85 and ending with a data field 86. Typically, block sequence 
number 84 is incremented with each new block sent by MPU 1. In the specific case 
under consideration, data field 86 is a request to purchase bingo cards 77 illustrated 
in Fig. 12 (a). Importantly, authentication field 85 is generated by MPU 1 as a 
5 predetermined function of at least one of the fields 33, 84 or 86 using a security key 82 
downloaded by PC 21 into MPU 1 over connectors 7 and 23. Due to authentication 
field 85, the entire data block 83 is secure even though some portions of the data block 
(e.g., 33, 84 and 86) may not be secure. Therefore, an unscrupulous player cannot 
advance a false claim that he or she did not play a particular game that resulted in a 

1 0 loss or that he or she won a large prize since no other player can realistically send out 
a properly authenticated data block 83. Also, given a sufficiently long authentication 
field 85 (e.g., five hundred and twelve bits), spurious radio frequency noise cannot 
realistically produce a false request by a player's MPU 1. Similarly, a "hacker" who 
does not know the true security key 82 cannot send a false game request in the place 

15 of a legitimate player. In summary, the casino is protected from false claims that might 
otherwise be advanced by cheats and "hackers" and players are more confident that 
gaming in the casino is fair and secure. 

[0061] Each response block 87 transmitted by UDK 2 to MPU 1 is also protected 
by an embedded authentication field 88 as shown in Fig. 13 (b) illustrating a "service 

< 

20 request" data block. In Fig. 13 (b), manufacturer's identification number 33 of an 
addressed MPU 1 is the destination address of data block 87, 89 denotes a block 
sequence number assigned by UDK 2 and 91 denotes a data field (e.g., bingo card 
contents). Only a specific MPU 1 addressed in the field 33 recognizes and 
authenticates data block 87 since only this specific device was downloaded by PC 21 

25 with a specific digital key 82 matching data block 87. A sufficiently long digital signature 
88 virtually guarantees that the outcome of the game shown on touchscreen 3 is correct 
rather than "hacked" by some prankster. 

[0062] The above-described technique of secure two-way communication between 
MPU 1 and UDK 2 over public RF channel 31 with the help of an encryption key 82 
30 downloaded by UDK 2 into MPU 1 over a secure wired channel is useful not only for 
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playing bingo games but is also beneficial for playing "classic" casino games, such as 
poker, slots and keno. For example, a player can play a slot game on MPU 1 by simply 
touching touchbutton "SPIN" 92 displayed on touchscreen 3. Once a player touches 
button 92, MPU 1 causes the image of reels 93 on display 3 to spin and transmits an 
5 encoded request 83 having data field 86 structured as "spin request" data block 94 
illustrated in Fig. 1 2 (b). The field 95 of block 94 specifies a number of coins the player 
wagered and the field "SPIN" 96 specifies a request to generate a random final position 
for the reels 93 to stop. Since MPU 1 is not a perse secure device, the outcome of the 
game cannot be determined by MPU 1 itself. Only secure PC 21 of UDK 2 can be 

10 trusted to generate random numbers on behalf of MPU 1 and thusly determine the 
prize, if any, won by MPU 1 . Upon receiving request 94, UDK 2 randomly generates 
a new final position for the "reels" 93 and transmits it in an encoded, authenticated form 
to MPU 1 . The MPU 1 decodes the response received from UDK 2 and gradually slows 
down the "reels" to a new final position determined by UDK 2. 

15 [0063] The above general outline of events involved in playing slots on MPU 1 is 
illustrated by flowcharts presented in Figs. 14 through 16. Specifically, Fig. 14 
illustrates the "initiate spin" task performed by MPU 1 in response to pressing 
pushbutton "SPIN" 92. Note that similarly to PC 21, MPU 1 also executes a 
multitasking application program preferably, in Linux® environment. The processing 

20 involves a repetitive polling of touchscreen button 92 by the embedded microprocessor 
of MPU 1 in the step "SPIN?" 116. The polling continues until a pressing of button 92 
is detected. Then, MPU 1 forms request 94 in the step "FORM REQUEST" 117. 
Subsequently, MPU 1 encodes request 94 into block 83 and transmits it via transceiver 
19jn the step "TRANSMIT REQUEST" 119. The request 83 sent by MPU 1 is received 

25 by UDK 2 and processed by its PC 21 in the step "RECEIVE REQUEST" 120 shown 
in Fig. 15 that illustrates a "determine outcome" task. Subsequently in the step 
"DECODE REQUEST" 121, PC 21 decodes the true request 94 from its received 
encapsulated form 83 using the encryption/decryption key 82 stored in table 35. In the 
same step "DECODE REQUEST" 121, PC 21 strips out the manufacturer's 

30 identification number 33 of MPU 1 that transmitted request 83. Using the decoded 

r 
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manufacturer's identification number 33, PC 21 then performs the step "FETCH UNIT 
RECORD" 122 by searching group 70 of table 35 for a record matching MPU1 that 
transmitted the received request 83. Subsequently, in the step "DECREMENT UNIT'S 
BALANCE" 123, PC 21, assuming the current balance 57 is sufficient, decrements a 
5 player's balance 57 by the amount of coins specified in the field 95 of request 94. At 
this point, PC 21 determines the random outcome of player's bet 95 by executing the 
step "GENERATE RANDOM OUTCOME" 124 involving a generation of a pseudo 
random number with the help of a conventional software utility. If the generated 
random outcome results in winnings as determined in the test step 125, PC 21 

10 increments a player's balance 57, by the amount won as specified in the paytable of 
the game stored in the memory of PC 21, in the step "INCREMENT PLAYER'S 
BALANCE" 126. Otherwise, PC 21 directly proceeds to the step "FORM RESPONSE" 
127. In the latter step, PC 21 forms data field 91 and the return address 33 of MPU 1 
and increments the block sequence number 89. Subsequently, PC 21 computes digital 

1 5 signature 88 utilizing the encoding/decoding key 82 in the step "ENCODE RESPONSE" 
129. Finally, PC 21 transmits the fully formed response 87 to MPU 1 via transceiver 
16. The response 87 of UDK 2 is received by MPU 1 in the step "RECEIVE 
RESPONSE" 1 30 and is decoded in the step "DECODE RESPONSE" 1 32 with the help 
of 1<ey 82. Specifically, the random outcome of the game 91 is filtered out and is 

20 presented on touchscreen 3 in the step "DISPLAY OUTCOME" 132 shown in Fig. 16 
illustrating a "display outcome" task. 

[0064] MPU 1 allows playing of a poker game in a similar manner. Specifically, a 
player touches a toggle touchbutton "DEAL/DRAW" 97 on touchscreen 3 requesting a 
new "deal." In response, MPU 1 forms a player's request block 83 with the data field 

25 86 structured in the form 98 of a "deal request" data block illustrated in Fig. 12 (c) 
wherein 99 is a number of coins the player bets while the request field 1 00 specifies a 
request to generate a random hand of cards. The request 98 is authenticated by MPU 
1 and relayed to UDK 2 in the form 83. Once UDK 2 receives "DEAL" request 98, PC 
21. sends a set of randomly generated cards back to MPU 1 in an encoded and 

30 authenticated format 87 with data field 91 structured as shown in Fig. 1 7 (a) illustrating 
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a "deal" data block. Specifically, Fig. 1 7 (a) illustrates a case wherein PC 21 generates 
a random deal hand consisting of the two of diamonds, seven of clubs, four of 
diamonds, five of diamonds and six of diamonds. The generated hand is encoded as 
a data block 101 shown in Fig. 17 (a) wherein 102 is a response identification field 
5 "DEAL" and 1 03 is a five-byte long data field containing encoded representation of dealt 
cards. The received random poker hand is displayed to the player by MPU 1 on its 
touchscreen 3. The player then makes his selection as to which cards to hold by 
touching respective cards on the screen 3 and presses the toggle touchbutton 
"DEAL/DRAW" 97. Once the player does so, MPU 1 sends a request 83 to UDK 2 with 

10 the data field 86 structured as "draw request" data block 104 illustrated in Fig. 12 (d) 
wherein the five consecutive fields 105 through 106 indicate respectively which cards 
the player decided to hold as indicated by their value being equal to one, and which 
cards are to be discarded as indicated by their value being equal to zero. The main 
field "DRAW" 1 1 0 indicates that this is a request to draw random cards to substitute for 

15 the cards the player decided to discard. In this specific case, the player makes an 
obvious choice to discard the "seven of clubs" and retain the rest of the dealt cards. 
In response, UDK 2 sends back an encrypted block 87 containing a data filed 
structured as block 111 shown in Fig. 17 (b) illustrating a "draw" data block. The 
response identification field "DRAW" 1 1 2 in Fig. 1 7 (b) indicates that this is an outcome 

20 of a poker game. Specifically, the five consecutive bytes of information following the 
"DRAW" field contain the drawn cards, the next two byte data field 113 contains the 
amount won by the player, and the last two byte data field 114 contains the player's 
new account balance. As illustrated in Fig. 17 (b), the drawn card is the "three of 
diamonds", the prize won as a result of the "straight" is one hundred coins, and the 

25 player's new balance is one hundred twenty coins. Note that MPU 1 does not have any 
responsibility for generating random numbers nor maintaining the current player's 
balance but rather simply displays the balance computed by UDK 2 on behalf of MPU 
1. 

[0065] In a manner similar to that described above, MPU 1 may be adapted to play 
30 virtually any casino game, including blackjack, keno, roulette, sports book and horse 
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racing. In fact, MPU 1 can play several games concurrently. For example, slots and 
bingo can be played concurrently as taught in U.S. Patent No. 4,856,787 to Itkis et al. 
Moreover, the preferred embodiment illustrated in Fig. 1 can be adapted to implement 
a broad variety of various applications without departing from the main principles of the 
5 invention. For example, although Fig. 1 shows only one UDK 2, a casino may have any 
number of such UDKs 2 installed throughout the property and integrated in an extended 
local area network. The networked UDKs 2 can interchange data over a local area 
network 22 extended beyond a single UDK 2 and can share a common player database 
35. In a casino equipped with a number of such networked UDKs 2, a player may rent 
10 MPU 1 from a first such UDK 2 and return it to a second such UDK 2. 

[0066] Moreover, the extended LAN 22 can be equipped with multiple connectors 
23 installed throughout the casino, such as near lounge chairs, for convenient player 
access as illustrated in Fig. 2 by MPU 1 that is positioned outside UDK 2 and is plugged 

0 

into. LAN 22 via a cable 1 1 5 leading to connector 23. Once securely downloaded inside 
15 UDK 2 with authentication key 82, MPU 1 can be carried by a player to any such 
external outlet of extended LAN 22. Once plugged into socket 23, MPU can directly 
communicate with UDK 2 over LAN 22 instead of RF channel 31 . Therefore, MPU 1 
can send to and receive from UDK 2 data blocks 83 and 87 over LAN 22. Advantages 
of such a "plug and play" arrangement include the virtual absence of noise, a much 
20 higher channel throughput as compared with RF channel 31 , and an additional level of 
security afforded by wired cables. These advantages may well outweigh the additional 
cost of running LAN 22 throughout casino. Of course, a "plug and play" MPU 1 still 
must be initially downloaded with secure encryption key 82 inside UDK 2, otherwise 
MPU 1 can be easily subverted in transit between UDK 2 and socket 23 installed on the 
25 casino floor. 

[0067] Although connectors 7 and 23 are described as the primary LAN 22 channel 
for downloading to MPU 1 by UDK 2, their communication function can also be carried 
out by infrared communication ports built into MPU 1 and UDK 2 as is illustrated in Fig. 
18: As shown in Figs. 18 (a) and 18 (b) respectively, MPU1 is equipped with infrared 
30 (IrDa) communications port 135, while LAN 22 is equipped with a matching IrDa port 
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137. Note that although infrared ports 135 and 137 are more expensive than 
connectors 7 and 23, the former do not require a precise alignment of the 
communicating devices and, therefore, are frequently utilized in PDAs for the purposes 
of communicating with downloading stations. Ports 135 and 137 allow UDK 2 to 
5 download MPU 1 through infrared channel 136. Moreover, a commercial wireless PDA 
equipped with an infrared port 135 can function as MPU 1 , provided it is downloaded 
by PC 21 not only with encryption key 82 and/or bingo pack 43 but also with the above- 
described executable program for playing casino games and such downloading is 
performed via an infrared communication port. Note that techniques of downloading 
1 0 executable files from a stationary device into a portable device are well known and not 
explained herein. Therefore, an opportunity for a player to bring to the casino a favorite 
PDA and use it as a personal slot machine may be very attractive for some casinos 
because it decreases the cost of owning and maintaining the rental fleet of MPU 1 
devices. 

* 

■ 

1 5 [0068] Similarly, an off-the-shelf programmable telephone equipped with a graphics 
display and menu-navigation keys 6 may serve as a MPU 1 . A broad variety of 
downloadable "third generation" telephones is available on the market. In case of a 
telephone-based implementation, a player may use his or her own telephone for playing 
casino games in the above-described manner, provided of course, that the player's 

20 telephone is downloaded with a security key 82 as a precondition for playing casino 
games. Assuming connector 7 is compatible with the downloading and recharging 
connector of such a telephone, a player may insert a telephone into any available or 
reserved slot 17 of UDK 2 and wait a few seconds while PC 21 downloads key 82 into 
the memory of the player's telephone. In addition to key 82, PC 21 also downloads the 

25 above-described casino games into the player's telephone. The downloadable casino 
games are preferably written in JAVA language since many modern commercial 
telephones are capable of downloading and executing application programs written in 
JAVA language. 

[0069] Infrared port 135 built into MPU 1 also allows for lateral communication 
30 between two MPUs 1 as illustrated in Fig. 18 (a). Two MPUs 1 can interchange 
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arbitrary data via their respective ports 135. Such a data interchange is secure 
provided two units 1 are placed in close proximity to one another and their IrDa ports 
1 35 are aimed at each other. Note that a likelihood of intercepting a line-of-site infrared 
communication between two closely located MPUs 1 by an outsider is negligible. This 
5 opens up an opportunity for utilization of a MPU 1 as a mobile point-of-sale terminal as 
indicated by numeral 138 in Fig. 18 (a). Specifically, one of the MPU 1 units may be 
allocated to a casino employee. Initially, MPU 1 allocated to a casino employee may 
be downloaded with a large number of bingo packs 43 as described above. 
Subsequently, the casino employee may dispense, via aligned infrared ports 135, a 

10 portion of the bingo packs 43 stored in its memory to a MPU 1 , PDA or telephone in 
possession of a player. The information about such an indirect downloading of player's 
MPU 1 by a casino employee may be reported by the employee's MPU 1 to UDK 2 via 
antenna 4. Since RF communication between the employee's MPU 1 and UDK 2 is 
inherently secure, the entire process of indirect downloading of the player's MPU 1 is 

15 also secure. The data downloaded into player's MPU 1 from the employee's MPU 1 
is not limited to bingo cards. A unique data encryption key 82 reserved for the player 
can be downloaded from the employee's MPU 1 along with monetary credits and 
casino games as well. 

[0070] A viable alternative to downloading files via communication ports 7 and 23 
20 and/or ports 1 35 and 1 37 is utilization of smart cards for transporting files from PC 21 
to MPU 1. Assuming card reader 11 is equipped with a smart-card reader/writer 
circuitry, the necessary files can be written onto a smart-card and subsequently read-in 
by MPU 1 that is also equipped with a smart card reader/writer peripheral. Since many 
modern PDA devices are equipped with smart-card readers/writers, the opportunity for 
25 a player to play casino games on his or her own PDA in a casino becomes even more 
feasible, assuming of course, the above-described security techniques are followed. 
[0071] Another alternative for inputting encryption key 82 into MPU 1 includes a 
player reading key 82 from receipt 44 and manually entering key 82 into MPU 1 via a 
touch-pad on touchscreen 3. Although manual entry of key 82 is subject to error, it may 

- 
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be used as a substitute for the downloading of key 82 in an effort to save costs or in the 
case of a failure of downloading the key 82 via connectors 7 and 23. 
[0072] Although the invention has been described in detail with reference to a 
preferred embodiment, additional variations and modifications exist within the scope 
and spirit of the invention as described and defined in the following claims. 
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